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Abstract. Purpose is crucial for privacy protection as it makes users 
confident that their personal data are processed as intended. Available 
proposals for the specification and enforcement of purpose-aware policies 
are unsatisfactory for their ambiguous semantics of purposes and/or lack 
of support to the run-time enforcement of policies. 

In this paper, we propose a declarative framework based on a first-order 
temporal logic that allows us to give a precise semantics to purpose-aware 
policies and to reuse algorithms for the design of a run-time monitor 
enforcing purpose-aware policies. We also show the complexity of the 
generation and use of the monitor which, to the best of our knowledge, 
is the first such a result in literature on purpose-aware policies. 


1 Introduction 

An important aspect of privacy protection is the specification and enforcement of 
purposes, i.e. users should be confident that their data are processed as intended. 
For instance, email addresses are used only for billing but not for marketing 
purposes. Unfortunately, as already observed several times in the literature (see, 
e.g., [30] for a thorough discussion), both specifying and enforcing purposes turn 
out to be difficult tasks. 

Specification. Following the seminal paper [O^, the specification of privacy con¬ 
straints consists of establishing when, how, and to what extent information about 
people is communicated to others. In the context of IT systems, this amounts to 
define policies governing the release of personal data for a given purpose. Such 
policies are contributed by the users of a system, also called data owners, and the 
organization running the system. The latter, besides enforcing their own policies, 
are also required to take into account laws, regulations, and directives imposed 
by local, national, and community governamental bodies. From a technological 
point of view, these policies are usually mapped to access control policies aug¬ 
mented with purpose constraints, which we call purpose-aware policies (some¬ 
times called privacy-aware access control policies in the literature, see, e.g., El)- 
In this paper, we do not consider the problem of deriving purpose-aware policies 
from the high-level and heterogenous privacy requirements mentioned above. We 
assume that this has been done and focus instead on the basic building blocks 
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of the models and specification languages underlying the policies. As observed 
in [mn], such building blocks are data-centric and rule-centric policies. In the 
former, every piece of information is associated with the purposes for which it 
can be used; examples are the policies in [5] or those expressed in the XACML 
Privacy Profile|^In the latter, rules specify under which conditions subjects can 
perform some action on a given piece of information for some purpose; examples 
are those in PITT] and those expressed in EPAbj^ Data-centric policies more 
easly support the expression of the privacy preferences of data owners while 
rule-centric policies permit the expression of complex constraints imposed by 
laws, regulations, and best-practices adopted by organizations to handle per¬ 
sonal data. Thus, both data- and rule-centric policies should be supported for 
the specification of purpose-aware policies. 

One of the most serious problems in purpose-aware policies is the lack of 
semantics for purposes, which are usually considered as atomic identifiers. This 
gives rise to arbitrariness in the interpretation of purposes; e.g., if the policy of 
a company states that emails of users are collected for the purpose of communi¬ 
cation, this allows the organization to use emails for both billing and marketing 
when the majority of users has a strong preference for the first interpretation 
only. To solve this problem, several works have observed that “an action is for a 
purpose if it is part of a plan for achieving that purpose” [35]. Among the many 
possible ways to describe plans, one of the most popular is to use workflows, i.e. 
collections of activities (called tasks) together with their causal relationships, 
so that the successful termination of a workflow corresponds to achieving the 
purpose which it is associated to. We embrace this interpretation of purpose and 
avoid ambiguities in its specification by using a temporal logic which allows us to 
easily express the causal relationships among actions in workflows associated to 
purposes. Additionally, the use of a logic-based framework allows us to express in 
a uniform way, besides purpose specifications, also authorization (namely, data- 
and rule-centric) policies together with authorization constraints, such as Sepa¬ 
ration/Bound of Duties (sod/bod). While temporal logics have been used before 
for the specification of authorization policies (see, e.g., [5^) and of workflows 
(see, e.g., m), it is the first time—to the best of our knowledge—that this is 
done for both in the context of purpose-aware policies. In particular, the capabil¬ 
ity of specifying Sod or bod constraints—which are crucial to capture company 
best practices and legal requirements—seems to be left as future work in the 
comprehensive framework recently proposed in |20j . 

Enforcement. Enforcing purpose-aware policies amounts to check if (Cl) a 
user can peform an action on a certain data for a given purpose and (C2) the 
purpose for which a user has accessed the data can be achieved. 

(Cl) is relatively easy and well-understood being an extension of mechanisms 
for the enforcement of access control policies (see, e.g., m for an overview) 
by considering the combined effect of rule- and data-centric policies. This is 
so because tasks are executed under the responsibility of users and tasks may 

^ docs.oasis-open.org/xacml/3.O/xacml-3.0-privacy-vl-spec-cd-03-en.pdf 
www.w3.Org/Submission/2003/SUBM-EPAL-20031110 
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perform actions on data. To permit the execution of a task t by a user u, it is thus 
necessary to check if u can perform all the actions Acts associated to t (under 
a given rule-centric policy) and the data—on which Acts are performed—are 
released by their data owners (under a given data-centric policy). 

(C2) is much more complex than (Cl) as it requires to foresee if there ex¬ 
ists an assignment of users to tasks that allows for the successful termination 
of the workflow. This is so because—as discussed above—a purpose is associ¬ 
ated to a workflow so that its successful execution implies the achievement of 
the purpose. The problem of checking (offline) if a workflow can successfully 
terminate, known as the Workflow Satisfiability Problem (wsp), is already com¬ 
putationally expensive with one Sod |33j . and moreover, the on-line monitoring 
of authorization constraints requires to solve several instances of the wSP [T^ . 
For purpose-aware policies, this implies that it is necessary to solve an instance 
of the WSP per user request of executing a task in the workflow associated to a 
given purpose. 

Contributions. The paper provides the following contributions: 

— The specification of a comprehensive framework for expressing purpose-aware 
policies which are a combination of data- and rule-centric policies together 
with workflows augmented with authorization constraints (Section]^ and, in 
particular, Figure [^. To the best of our knowledge, this is the first time au¬ 
thorization constraints are considered and naturally integrated in a purpose- 
aware setting. 

— The semantic formalization of purpose-aware policies as formulas in first- 
order temporal logic (Section [3T| ). 

— The provision of formal techniques not only for the (on-line) enforcement of 
purpose-aware policies, but also for their (off-line) analysis, together with 
decidability and complexity results (Section]^. 

The choice of a first-order (linear-time) temporal logic for the semantics of 
purpose-aware policies has three main motivations. First, since both data- and 
rule-centric policies can be seen as access control policies, the use of first-order 
logic formulae to express them is adequate following the established tradition 
of expressing a wide range of access control policy idioms in (fragments of) 
first-order logic; see, e.g., |22l3j . In the rest of this paper, we do not elaborate 
further on this issue as it is well-studied and focus on aspects more closely re¬ 
lated to purposes. We just remind that answering a request of performing an 
action on an object by a user can be efficiently done (linear time in the size 
of the authorization query) as shown in, e.g., |22I3] . The second motivation for 
choosing a temporal logic comes from the declarative approach to the speci¬ 
fication of workflows proposed in |34l2j which provides a formal semantics to 
their executions. The third motivation is the adaptation and reuse of available 
results |l8ll,^llb| concerning logical problems in a combination of first-order and 
linear-time temporal logic to which verification problems for purpose-aware poli¬ 
cies can be translated. Additionally, it allows us to reuse available algorithms 
for solving logical problems on top of which a module for the the enforcement 
of purpose-aware policies can be built. 
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A running example (Section introducing the main issues related to 
purpose-aware policies is used through! the paper to illustrate the main concepts 
of our framework. Related work and conclusions are also discussed (Section]^. 

2 Running example 

We describe a running example, based on Smart campu^ which will be used 
throughout the paper. Smart campus is a platform in which citizens, institu¬ 
tions and companies can communicate with each other by exchanging data and 
services. It provides functionalities to access information about transportations, 
social services, education, and user profiles. These services allow companies to 
build new applications and thus offer new services to citizens. In this kind of 
scenario, personal data of users is the main ingredient to provide customized 
services. Indeed, users should be confident that the services access only the data 
required to their needs and use them for the right purposes. Additionally, service 
providers should comply with laws, regulations, and best practices in handling 
data mandated by local governments, the European Union, and enterprises. In 
other words, access to personal data must be mediated by appropriate autho¬ 
rization policies augmented with purpose constraints so that only authorized 
subjects have the right to access certain data for a given purpose. Following an 
established line of works (see, e.g., [20] for an overview), we assume that the 
purpose of an action is determined by its relationships with other, interrelated, 
actions. 

For concreteness, we illustrate these ideas by considering the situation in 
which some personal data of users in the Smart campus platform (namely, the 
work experience and the academic transcripts) is accessed by JH, a job hunting 
company, for the purpose of finding jobs to students. JH has deployed in the 
Smart Campus platform the service depicted of Figure(upper half), specified 
in the Business Process Model and Notation (bpmn). The swim lane labelled 
‘Student’ contains the activities (also called tasks) that must be executed under 
the responsibility of the data owner and the swim lane labelled ‘JH company’ 
shows the activities that employees of JH are supposed to perform for the pur¬ 
pose of finding some jobs to the data owner. First of all, an employee of JH per¬ 
forms an interview to the student to understand his/her job preferences. Then, 
the student decides to give or not his/her consent for JH to access his/her aca¬ 
demic transcripts by executing either task optin or task optOut, respectively (the 
empty diamond before the two tasks in Figureis an exclusive-or gateway). If 
he/she opts in, an employee of JH can access both his/her academic transcripts 
and past experience (by executing both getExms and getExp since the diamond 
containing the plus sign before the two tasks in Figureis a parallel gateway); 
otherwise, only the student past experiences can be accessed. Based on the in¬ 
terview and the collected personal information, an employee of JH search for 
jobs the student can be interested in (task findJobs) and some other employee 
proposes him/her some of them (task propJobs). Finally, the students decides 

® http://www.smartcampuslab.it 
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Fig. 1: The JobHunting workflow expressed in bpmn (upper half) and as a (par¬ 
tial) set of LTL formulae (lower half). 


if choosing one of the jobs or to abort the process (tasks chooseJob and abort, 
respectively). Further authorization constraints are imposed on which employees 
can execute task interview, find Jobs, and propose Jobs: the first two must be exe¬ 
cuted by different employees to keep the overall process unbiased—this is called 
a Separation of Duty (sod) constraint—whereas the first and last tasks must 
be executed by the same employee so that the student gets in contact with the 
same person of JH—this is called a Bind of Duty (bod) constraint. (In Figure[^ 
these constraints are shown as dotted lines connecting the tasks labelled by the 
distinct ^ or equal = sign in case of Sod or bod, respectively.) 

To summarize, the workflow specification is used to specify the purpose of an 
activity (task) with respect to all the others that must be executed for achiev¬ 
ing the given purpose. From now on, we assume that a workflow is uniquely 
associated to a purpose or, equivalently, that the semantics of a purpose is its 
associated workflow. 

Since the tasks in the workflow are executed under the responsibility of a 
user (e.g., an employee of JH), he/she must have the right to access such data. 
For instance, the task getExp takes as input the list of past job experiences of the 
student. The employee of JH executing this task must have the right to access 
such a list and the student should have given the consent to access this informa¬ 
tion to (an employee of) JH. In other words, every time an employee of JH asks 
to execute an activity for the purpose of finding jobs, he/she not only must have 
the right to do so according to the authorization policy of the company but also 
the student (data owner) should agree to release the information for the purpose 
of finding jobs. In other words, there are two types of policies that must be taken 
into account when granting the right to execute a task to an employee: one is 
called rule-centric^ and constrains access by considering subjects, actions, and 
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data objects while the other is called data-centric, and is such that data owners 
constrain access to their data objects for certain purposes only. For instance, in 
the job hunting scenario, the rule-centric policy specifies that employee bob has 
the right to read the list of job experiencens of students and the data-centric 
policy specifies that student sam’s academic transcripts can be accessed for the 
purpose of JobHunting. 

Notice the subtle interplay between purposes, described by workflows, and 
authorization policies. For instance, the execution of certain tasks can modify 
both rule- and data-centric policies as it is the case of optin and optOut in 
Figure[2 When executing the latter, the execution of the task getExms is skipped 
in the current instance of the workflow despite the fact that sam has agreed to 
disclose such information according to the above data-centric policy (for which 
sam’s academic transcripts can always be used for the purpose of jobHunting). 
This flexibility allows us to model certain data directive for privacy (see, e.g., [T]) 
in which the data owner must explicitly give his/her consent to access his/her 
personal data, every time it is requested. 

Finally, observe that handling purposes in presence of authorization con¬ 
straints (such as SOD or bod) requires to solve, at run-time, the Workflow Sat¬ 
isfiability Problem (wsp) [12], i.e., to be able to answer the question: does there 
exist an assignment of authorized users (according to the rule- and data-centric 
policies) to workflow tasks that satisfies the authorization constraints (soD or 
bod)? The WSP is known to be a computationally expensive activity; it is already 
NP-hard with one Sod constraint |33|. To make things even more complex, at 
run-time, we need to solve several instances of the WSP, one per user request of 
executing a task in a workflow associated to a purpose. This is so because to 
solve an instance of the wSP, it is sufficient to find an execution sequence of task- 
user pairs containing all the tasks in a workflow. In the job hunting scenario, 
consider the initial request of an employee uq to execute task interview. This 
implies to check whether there exists a sequence tt = (interview, wq), tt' of task- 
user pairs form which is a successful! execution of the workflow. For instance, if 
tt' is (optOut, sam), (getExp, Mo), (findJobs, ui), (propJobs, uo), (abort, sam), then 
TT represents a succesfull execution of the workflow when sam decides to opt 
out and not releasing his academic transcript to JH. However, this implies only 
that the WSP is solvable and the sequence represents a possible future execution. 
Imagine now that sam decides to opt in: tt' is useless and a new instance of 
the WSP must be solved to find a successful execution of the workflow of the 
form (interview, Mo), (optin, sam), tt" for some sequence tt". Notice that, even if 
sam decides to opt out, the sequence tt' may be useless, provided that a user M 2 
distinct from mq is granted the possibility to execute task getExp. 

3 A Declarative Framework for Purpose-aware Policies 

On the left of Figure it is shown an entity-relationship diagram describing 
the conceptual organization of our framework (rectangles represent sets of enti¬ 
ties and diamonds relationships among them). We have DataOwners who own 
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Purpose 

specification 


dcp C DataObjects x DataOwners x Purposes 
rep C Subjects x Actions x DataObjects 


def : Purposes —>■ Workflows 
cont C Workflow x Tasks 
uses C Tasks x Actions x DataObjects 
sod C Workflows x Tasks x Tasks 
bod C Workflows x Tasks x Tasks 


Fig. 2: Conceptual representation of the data-, rule- and purpose-centric policies. 


DataObjects and decide the Purposes for which these can be accessed by means 
of a data-centric policy (relation dcp). Subjects can perform certain Actions 
on DataObjects according to a rule-centric policy (relation rep). Purposes are 
defined (relation def) in terms of Workflows which are composed of Tasks (re¬ 
lation cont) and Sod or bod constraints; each task can perform some Actions on 
DataObjects (relation uses). 

On the right of Figure it is shown the formal characterization of the rela¬ 
tionships as subsets of the cartesian products of the appropriate sets of entities. 
To illustrate, recall the running example in Section 

— the rule- and data-centric policies “bob has the right to read the list 
of job experiencens of students” and “sam’s academic transcripts can 
be accessed for the purpose of JobHunting” can be specified by rela¬ 
tions rep and dcp which are such thalQ rcp(bob, read,JobExpList) and 
(icp(academicTranscript, sam,JobHunting); 

— if yi is the specification of the workflow in the upper half of Figure (we 
explain below what is tp), then de/(JobHunting) = tp (notice that def is a 
total function from Purposes to Workflows, i.e. every purpose is associated 
to a workflow); 


Given an n-ary relation R, we write R{ei, ...,e„) for (ei,..., Cn) £ R. 
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— the SOD and Bod contraints in Figure can be specified by relations sod and 
bod such that sod(</j, interview, findJobs) and 6o(i((/5, interview, propJobs); 

— the fact that, for example, tasks interview and optin are part of the worfiow 
specification ip can be specified by a relation cont such that cont((p, interview) 
and cont((/3, optin); 

— the fact that the task interview reads the user profile can be specified by a 
relation uses such that Mses(interview, read, UserProfile); 

We now explain how we specify workflows in our framework. Following the declar¬ 
ative approach in [2], we have chosen Linear-time Temporal Logic (ltl) as the 
specification language. The main reason for this is two-fold. First, well-known 
techniques (see, e.g., [U]) are available to translate procedural descriptions of 
workflows (e.g., that in the upper half of Figure [^, and more in general con¬ 
current systems, to ltl formulae. For instance, the lower half of Figure shows 
an (incomplete) set of ltl formulae (to be read in conjunction) corresponding 
to the BPMN workflow in the upper half. The first conjunct on the left means 
that interview must be the first task to be executed, formula ^getExmsiY optin in 
the third conjunct of the figure means that the academic transcripts cannot be 
accessed if the student has opted out. Formula ^findJobsiY(getExmsVgetExp) in 
the fourth conjunct means that the execution of task find Jobs must not happen 
before the execution of getExms or getExp. 

The second reason for chosing ltl to specify workflows is that it allows us to 
derive a precise semantics of purpose-aware policies and to reuse available tech¬ 
niques for the off-line and on-line verification of formulae to support the analysis 
of policies at design-time and their enforcement at run-time. Such verification 
tasks are presented in Section Here we focus on the semantics of purpose- 
aware policies, starting with the meaning of ltl formulae, which are expressions 
of the following grammar: 

ip ::= a \ \ Pi f\P 2 \ Op \ PiU P 2 \ Op \ Op with a G Prop 

where Prop is a set of Boolean variables representing tasks. Intuitively, Op 
means that p holds at the next instant, pi U p 2 means that at some future 
instant p 2 will hold and until that point pi holds, Op means that p always 
holds, and its dual Op that p eventually holds. Since we assume workflows 
to eventually terminate, we adopt the finite-trace semantics in |15I16] . The only 
notable aspect of this semantics (with respect to the standard semantics as given 
in, e.g., [H]) is that Op is true iff a next state actually exists and it satisfies 
p. The models of ltl formulae are finite sequences of Boolean assignments to 
the variables in Prop indexed over natural numbers, which represent instants 
of a linear and discrete time. The idea is that at a certain time instant, the 
Boolean variable representing a task is assigned to true iff the corresponding 
task has been executed. As customary in workflow specifications, we assume 
that one task only is executed at a time. By looking at a sequence of Boolean 
assignments satisfying a formula, we can thus understand which tasks have been 
executed and which are not. In other words, a sequence il of Boolean assignments 
satisfying a formula p, in symbols 11 \= p, correspond to a possible execution 
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of the workflow described by ip (see |15ll6j for a precise definition). The set of 
all sequences satisfying a formula ip, i.e. the set of all successful executions of 
the workflow described by ip, is called its language and is denoted by L{ip). It 
is possible to build an automaton (i.e., a finite-state machine) from a formula 
if accepting exactly all the traces belonging to C{ip)-, see again |15llbj for the 
description of the procedure for doing this. 

We can now define the notion of purpose-aware policy as a tuple 

V = {DataOwners, Subjects, DataObjects, Actions, Tasks, 

Workflows, Purposes, dcp, rep, sod, bod, cont, def) 

whose components are as explained above. 

As it is standard in access control models, we introduce the notion of a 
request as a tuple {wid, sub, tsk, do, p) where sub S Subjects, tsk G Tasks, 
do G DataOwners, p G Purposes, and wid belongs to the set Wid of work- 
flow identifiers (allowing us to distinguish among different executions of pos¬ 
sibly the same workflow). Intuitively, [wid, sub, tsk, do,p) means that subject 
sub asks the permission to execute task tsk on the data objects owned by the 
data owner do in the workflow instance wid for the purpose p. The relation 
req C Wid x Subjects x Tasks x DataOwner x Purposes contains all possible 
requests. 


3.1 Semantics of purpose-aware policies 


We explain how a request [wid, sub, tsk, do,p) is granted or denied according to 
a purpose-aware policy P. The idea is to derive a first-order ltl formula from 
the LTL formula def[p) constraining the ordering of requests such that the rule-, 
data-centric policies and Sod and bod constraints are satisfied. Thus, instead of 
sequences of Boolean assignments, we consider first-order models which differ 
for the interpretation of requests only. For the sake of brevity, we do not give a 
formal semantics of first-order ltl on hnite-traces but only some intuitions and 
refer the interested reader to [T5] for the details. 

First of all, we observe that every workflow instance can be considered in iso¬ 
lation since the framework presented above allows one to specify only constraints 
within a workflow instance and not accross instances. For this reason, we intro¬ 
duce an operator to identify requests referring to the same workflow instance wid 
out of a trace 77 containing requests referring to arbitrary workflow instances, i.e. 
^Iwid = reqi[w\d, subi, tski, doi, p),..., re( 7 „(wid, subn, tskn, do^, p) is the trace 
representing the evolution of the specific workflow instance wid. Notice that re¬ 
quests in 77 1 wid share the same workflow identifier wid and purpose p whereas 
subjects, tasks, and data owners may be different. Given a purpose-aware policy 
V, for each purpose p G Purposes such that def[p) = ip, we build a (first-order) 
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LTL formula ■= tp A A f\ E /\ B where 


A 

E 


y/y t -H- Bsub, do. 

cont{(p,t) 


( reg(wid, sm&, t, do, p)A 

V /\uses{act,t,obj) dcp{do, obj, p) A rcp{sub, act, obj) 


/\ ^{ti,t2,=)Aat2,ti,=) 

Sod{(p,ti ,t2) 


B ■■= /\ ({ti,t2,^) A 

bod{ip,ti ^ 2 ) 


:=Dysub, sub'. 


f V(io.req(wid, sub, t, do, p)A 
Oydo.req{w\d, sub', t', do, p) 


—>■ sub (XI sub'. 


Formula A says that in order to execute task t for purpose p, we need to check 
that subject sub who has requested to execute it is entitled to do so according to 
both the rule- and data-centric policies in V, thus formalizing the check (Cl) in 
the introduction. Formulae E and B encode the Sod and bod constraints in V, 
respectively, which are both derived from the same template formula 
saying that if a request for executing t' is seen after that for executing t, then 
the two subjects performing such tasks must be either different (when ixi is 7 ^, 
i.e., in case of a sod) or equal (when (xi is =, i.e., in case of a bod). Formulae p, 
E and B, thanks to their temporal characterization, formalize the check (C2) in 
the introduction. A sequence of requests for a purpose p and an instance 

wid of the workflow def{p) satisfies the purpose-aware policy V iff 7T|id H ^p- 
By abusing notation, we write C{p) for all such sequences. Given a sequence 
a of (previous) requests, a (new) request r = (wid, sub, tsk, do, p) is granted by 
the purpose-aware policy V iff wid is an instance of the workflow def{p) and 
there exists a sequence a' of requests such that a,r,a' is in C{p); otherwise, it 
is denied. 

To illustrate some of the notions introduced above, let us consider the first- 
order LTL formula that can be derived from the example in Section As already 
observed, the formula p associated to the purpose JobHunting is the conjunction 
of the formulae in the lower half of Figure]^ The conjunct in A for interview is 

( req{\N\d, sub, interview, do, jobHunting)A 
dcp{do, userProfile,jobHunting)A 
rcp{sub, read, userProfile) 



The formula representing the Sod constraint between interview and findJobs is 


□Vsm5, sub'. 


f ydo.req{wid, sub, interview, do, jobHunting)A 
0\/do.req{wid, sub', findJobs, do, jobhunting) 


0\/sub, sub'. 


f ydo.req{wid, sub, findJobs, do, jobHunting)A 
<>\/do.req{wid, sub', interview, do, jobhunting) 


-A sub 7 ^ sub' A 
-A sub 7 ^ sub' . 


Notice that the second conjunct above can be dropped without loss of generality 
since, from de/(jobhunting), it is possible to derive that it is never the case that 
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task find Jobs is executed before task interview. From a complete specification of 
the purpose-aware policy V for the running example, it is not difficult to see 
that the request tq = (wid, bob, interview, sam, jobhunting) is granted by apply¬ 
ing the definition given above as follows. First, take a to be the empty sequence 
as ro is the first request. Second, we can derive that task interview can be ex¬ 
ecuted from the formula for interview above and the fact that V is such that 
dcp(sam, userProfile,Jobhunting), i.e. sam decided to release his user profile for 
the purpose of job hunting, and rcp(bob, read, userProfile), i.e. bob has the right 
to read user profiles. Third, take a' = r-i,r 2 ,rs,r 4 ,rs for 

ri := (wid, sam, optOut, sam, jobhunting) r2 := (wid, bob, getExp, sam, jobhunting) 
rs := (wid, adam, find Jobs, sam, jobhunting) r4 := (wid, bob, propjobs, sam, jobhunting) 
rs ;= (wid, sam, choosjob, sam, jobhunting) 

where ri corresponds to the fact that sam has opted out and only his past expe¬ 
riences can be released, r2 to the fact that bob can retrive sam’s past experiences 
(as said in Section]^, to the fact that the jobs for sam are found by adam, who 
is distinct from bob in order to satisfy the Sod constraint between interview and 
findJobs in Figure (indeed, we assume that bob can execute getExp according 
to 7 ^), r4 to the fact that the list of found jobs is proposed to sam by bob in 
order to satisfy the bod constraint between interview and propJobs in Figure 
and r5 to the fact that sam decides to pick a job from the proposed list. 

We close the Section by remarking that this technique allows to discover 
inconsistencies as soon as they occur, i.e., at the earliest possible time. This 
is sometimes called early detection in the bpm literature, and it is a no¬ 
table feature of temporal logics. To explain the concept, assume that, ac¬ 
cording to V, only bob can perform the activities of jobhunting: when tq = 
(wid, bob, interview, sam, jobhunting) (or actually any other request for purpose 
jobhunting) is presented to the system, we are able to understand that no execu¬ 
tion can ever successfully complete the workflow, as sooner or later task findJobs 
must be executed by someone different from bob which however does not have 
the rights to do it. As a result, tq is denied and hence bob is not granted to 
access the data even if, by observing the current state, there is no evidence yet 
of any violation. 

The decidability and complexity of answering requests is studied in the fol¬ 
lowing section. 


4 Policies verification 


We now formalize, provide a solution and give complexity results to the following 
verification tasks: 

Purpose achievement problem : given a purpose-aware policy V and a purpose 
p, is it possible to successfully execute workflow c?e/(p)? That is to say: is 
it possible to assign tasks to subjects such that policy V is satisfied and the 
workflow successfully terminates? 
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req{wid, subi, interview, 


do,jobHunting) A 
subi ^ sub4 


3 sub, do. 

req{wid, sub, getExp, 


req(wid, 5^64, findJobs, 


do,jobHunting) A 
subi ^ sub4 



do, jobHunting) 





Fig. 3: An excerpt of the pre-automaton for formula ^jobHunting- 

Runtime policy enforcement : given a purpose-aware policy V, the current work- 
flow execution trace tt, and a new request can be granted or must be 
denied in order for the workflow to eventually terminate (check (C2) in the 
introduction) and such that the sequence of granted request always satisfies 
r (check (Cl))? 

4.1 Purpose achievement problem 

Technically speaking, this problem amounts to check, given a purpose p in a 
purpose-aware policy V, if is satisfiable, i.e., if there exists a trace TTl^id 
(where wid is a generic identifier for workflow de/(p)) such that 7T|wid |= ^p- 
We adopt an automata-based approach to solve the problem, which consists 
in building the automaton for and check if there exists a path to a final 
state. Since <Pp is first-order, we exploit the modularity of our framework and 
the of symbolic techniques in m to build the automaton with a reasonable com¬ 
plexity. Indeed, we notably separate sub-formulas in <?p checking the workflow 
((/?), checking rcp/dcp (A) and checking Sod/bod constraints Moreover, 

we observe that while (p and IJ,B typically remain fixed as they describe the 
workflow, rep and dep policies may occasionally change. From these consider¬ 
ations, we decouple the construction of the automaton checking the workflow 
constraints only, which we call pre-automaton, from that taking also care of rep 
and dep, called specmlzzed-automaton, so as when rep and dep change, we do 
not need to re-compute the automaton from scratch, but we just “adapt” the 
already computed pre-automaton to the new policies. 

The pre-automaton is a finite-state machine with edges labeled with first- 
order formulas. Figure shows an excerpt of the pre-automaton for <^jobHunting: 
where we notice that variables for subjects involved in Sod or BoD constraints are 
/ree, i.e., not bounded by any quantifier. Indeed, as tasks interview and jobHunting 
must be executed by different subjects (sod), variables for such subjects, namely 
subi and sm& 4 , are free and must be different. 

Theorem 1. Given a purpose-aware policy V, and a purpose p with def{p) = tp, 
the construction of the pre-automata Ap requires exponential space in the number 
of temporal operators of p, sod and bod. 

Proof (sketch). Automaton Ap is built from <Pp using the algorithm for 
the propositional case over finite traces by simply ignoring constraint 

f\uses(act,t,obj)^^P{^^^^^Af‘) ^ rcp(sub, act, obj) and quantifiers Vsu 6 i,su 62 of 
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sub-formulas S and B and considering first-order atoms as propositional sym¬ 
bols (see m for details). Observing that ip, S and B are the only sub-formulas 
which contains temporal operators, and hence, the only source of complexity, 
and recalling that building the automaton for a propositional formula requires 
exponential space in the number of temporal operators [T5], i.e., in 

the worst case, the claim follows. □ 

A pre-automaton can be specialized to take into account a specific set of 
rep and dep by simply adding, to each edge labeled with req{wid, sub,t, do, p), 

the constraint Aact,objeuses{act,t,obj)(.dcp{do,obj,p) A rcp{sub,act,obj)). Notice 

that such an operation is legitimate as sub-formulas (A) checking rep and dep 
do not contain any temporal operators. The resulting specialized-automaton 
Ap is a symbolic structure where we check whether there is a way to reach 
a final state—thus solving a workflow satisfiability problem—by trying to 
satisfy formulas on edges. Indeed, satisfy a formula (w.r.t. V) precisely means 
assigning a task to a subject which is authorized by V to perform it. Consider, 
e.g., formula 3su6, do.req(u;ffi, su 6 , findJobs, do, JobHunting) on edge from qj 
to qs in Figure its corresponding formula in the specialized automaton is 
3sub, do.req{wid, sub, findJobs, do,JobHunting) A«ses(act.findjobs.obj) dcp{do, obj, p)A 
rep{sub,act,obj). Assuming that bob has the rights to perform getExp, the 
substitution hoh/sub satisfy the formula according to V, and so that edge can 
be use to build a path to a final state. Analogously, the assignment bob/su6i 
and adam/su 64 satisfies formulas on edges from <70 and q^ respectively. When 
no such an assignment can be found, the workflow cannot be successfully 
completed given policy V. 

Theorem 2. Given a finite purpose-aw are policy V and a purpose p with 
de/(p) = ip the purpose achievement problem can be solved in exponential time 
in the size of ip, sod and bod. 

Proof. Given a specialized automaton Ap, in the worst case all possible assign¬ 
ments to variables in edges must be checked. Such assignments are finite as the 
purpose P is finite and exponential in the number of variables. Actually, it can be 
proven (see [TB]) that it is enough to try substitutions for subjects involved in Sod 
and BOD constraints only, which usually are of a much smaller number. This is 
because sod and bod constraints generate variables which occur throughout the 
whole automaton (across-state variables) and are the only source of complexity 
(such as subi and sub^ in Figure]^. Any other variable, instead, is local, i.e., it 
occurs in a specific formula only, whose formula can be checked for satisfiability 
by simply querying V. For each substitution to across-state variables a reachabil¬ 
ity test to a final state (linear in the size of the automaton) must be performed. 
From Theorem]^ we get time complexity of \Subjects\^^°^'^°^^ ■ . 


4.2 Runtime policies verification 

Given a sequence tt of (previous) requests and a new request r, should we allow 
r or not? 
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Traditional ltl semantics presented in the previous Section is not adequate 
for evaluating requests at runtime, as it considers the trace U seen so far to 
be complete. Instead, we want to evaluate the current request by considering 
that the execution could still continue and this evolving aspect has a significant 
impact on the evaluation: at each step, indeed, the outcome may have a degree 
of uncertainty due to the fact that future executions are yet unknown. 

Consider, e.g., that so far request rg has been granted, where rg := 
(wid, bob, interview, sam,jobHunting) is as in the previous Section. Assume that 
now request ri := (wid, sam, optOut, sam,jobHunting) is presented and must be 
evaluated: we may be tempted to use the traditional ltl semantics, which re¬ 
turns TT : rg,rI ^ because some constraints have not been satisfied (such as: 
“eventually findJobs must be executed”) but this is not a good reason to deny 
request ri, as the workflow execution will not stop after ri (and actually any 
other single request different from ri would not have satisfied anyway). 

A more complex analysis is hence required, which assesses the capability of a 
partial trace to satisfy or violate a formula (p in the future by analyzing whether 
it belongs to the set of prefixes of C{(p) and/or the set of prefixes of 
Roughly speaking, let n : rg,ri be as before: we want to check if there exists a 
possible sequence of future requests tt' : r 2 ,r 3 ,.. .r„ such that tt,tt' |= ^p and, 
if this is the case, we grant request ri. We can actually be more precise, and 
evaluate the current request in four different ways. 

Given a (partial) trace tt, a formula (Pp and a new request r, we adopt the 
runtime semantics in m which is such that: 

— TT, r ^ [^p]rv = temp^true, when 7r,r temporarily satisfies <Pp, i.e., tt is 
currently compliant with <Pp, but a possible system future prosecution may 
lead to falsify ^p; 

— TT,r \= [^pJrv = temp_false, when that the current trace temporarily falsify 
^p, i.e., 7r,r is not current compliant with <?p, but a possible system future 
prosecution may lead to satisfy (Pp; 

— 7r,r (= [^pJrv = true, when 7r,r satisfies 'Pp and it will always do, no matter 
how it proceeds; 

— TT, r 1= [^pJrv = false, when tt, r falsifies Pp and it will always do, no matter 
how it proceeds. 

A new request r is denied if 7r,r )= [<?p]rv = false, and granted otherwise. 

Intuitively, every time a new request is presented, we check that: (z) from the 
current automaton state there exists an outgoing edge whose formula is satisfied 
by the current request (which corresponds to check (Cl) in the introduction) 
and (ii) from the arrival state there exists a path to a final state, which is a 
WSP that exactly corresponds to check (C2). Such analyses are performed on 
an automaton which is different from the one presented in the previous Section, 
as it not only has to check prefixes of Pp, but also that of ^Pp, in order to 
distinguish among the four cases above (see m for details). However, the same 
idea of the pre- and specialized automata also apply to this case. 

Once the specialized-automaton has been computed, the current sequence 
of requests is analyzed. Notice that, differently from the offline verification. 


Purpose-aware monitoring of authorization constraints 


15 


assignment of users to tasks are partially given by the current and previous 
requests, and hence we have to check if such partial assignments can be ex¬ 
tended, according to policy V, in order to reach a final state. Consider again 
ro := (wid, bob, interview, sam,jobHunting) to be the already granted request 
and ri := (wid, sam, optOut, sam, jobHunting) to be the current one. Request 
ro provides the assignment bob/su6i which forces us to solve the WSP with the 
additional constraint of subi = bob. Actually, 7’o,ri ^ [??p]rv = temp-false, as 
^ 0 ; ''^1 ^ but there exists a sequence of assignments of users to tasks that even¬ 
tually satisfies it, which is sequence ?' 2 ,r 3 ,r 4 ,r 5 shown in the previous Section. 
We remark that a wSP instance must be performed each time a new request is 
presented. Indeed, the actual next request f 2 (still unknown at the current time) 
is in general different from r 2 , and hence sequence ^ 2 , ?’ 3 , ?’ 4 , ^’5 found at this step 
as a witness of a possible future execution is of no use as the system progresses. 
Notably, the fact that we discover inconsistencies at the earliest possible time 
(early detection) allows us to block workflow executions exactly when a possible 
successful path can still be followed. When this is not guaranteed, the online 
enforcement is inefficient as when the precise point of deviation from the right 
path is unknown: (i) possible several tasks are executed before realizing the in¬ 
consistency (hence several data are accessed thus breaking the security) and {ii) 
possibly it is too late to recover the execution. 

Theorem 3. Given a purpose-aware policy V and a purpose p with def{p) = (p, 
the runtime policy verification requires, at each step, exponential time in the size 
of (fi, sod and bod. 

Proof (sketch). The construction of the specialized automaton for monitoring 
incoming requests for workflow def{(p) require the same complexity of the au¬ 
tomaton in Theorem (see [TS] and m)- When a new request r is presented, a 
WSP instance must be solved, as explained in m- Being the complexity of wSP 
as in Theoremthe claim follows. □ 

5 Discussion and Related Work 

We have presented a declarative framework to specify and enforce purpose-aware 
policies. In the literature, several proposals have attempted to characterize the 
notion of purpose in the context of security policies. Some of them (e.g., [10) 1 
propose to manage and enforce purpose by self-declaration, i.e. subjects explic¬ 
itly announce the purpose for accessing data. While this provides a first effort 
to embody purpose in access control policies, these approaches are not able to 
precent malicious subjects from claiming false purposes. Other works (e.g., [29]) 
propose to extend the Role Based Access Control model with mechanisms to 
automatically determine the purpose for which certain data are accessed based 
on the roles of subjects. The main drawback of these approaches is the fact that 
roles and purposes are not always aligned and members of the same role may 
serve different purposes in their actions. Other approaches (e.g., m) are based 
on extensions of (Attribute Based) Access Control models for handling personal 
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data in web services or (e.g., [30]) on extensions of Usage Control models for 
the distributed enforcement of the purpose for data usage (see, e.g., |1H])- The 
main problem of these approaches derives from the limited capability of the 
application initiating the handling of personal data to control it when this has 
been transferred to another (remote) application in the distributed system. Our 
framework avoids this problem by assuming a central (workflow-based) system 
acting as a Policy Enforcement Point (PEP) intercepting all requests of exe¬ 
cuting a particular action on certain data. Such an architecture for the PEP is 
reasonable in cloud-based environments (e.g., the Smart Campus platform briefly 
described in Section]^ in which services and applications are implemented via of 
Application Programming Interfaces (APIs) so that remote applications provide 
only the user interface while the control logic is executed on the cloud platform 
and can thus be under the control of the central PEP. 


The common and more serious drawback of the approaches considered above 
is that they fail to recognize that the purpose of an action (or task) is determined 
by its position in a workflow, i.e. by its relationships with other, interrelated, 
actions. This observation has been done in more recent works—e.g., |32l27l2nj — 
and is also the starting point of our framework in this paper. We share the effort 
of formalizing the notion of purpose as a pre-requisite of future actions. In future 
work, we would like to study how hierarchical workflows (i.e. workflows contain¬ 
ing complex activities, specified in terms of lower level tasks) can be expressed 
in our framework so as to capture the specification of purposes as high-level 
activities as done in |20j . The main difference with previous works is our focus 
on run-time enforcement of purpose-aware policies while [32j and m on audit¬ 
ing. Furthermore, the formal framework adopted to develop these proposals are 
different from ours: |32| uses Markov Decision Processes, m a process calculus, 
and [20] an o-d hoc modal logic. These choices force the authors of [271^ to 
design algorithms for policy enforcement or auditing from scratch. For instance, 
[20] gives a model checking algorithm on top of which a run-time monitor for 
purpose-based policies can be implemented, without studying its complexity. In 
contrast, we use a first-order temporal logic which comes with a wide range 
of techniques to solve logical problems (see, e.g., m) that can be reused (or 
adapted) to support the run-time enforcement of purpose-aware policies. For in¬ 
stance, we were able to derive the first (to the best of our knowledge) complexity 
result of answering authorization requests at run-time under a given purpose- 
aware policy: exponential time in the number of authorization constraints (The¬ 
orem]^. This complexity is somehow intrisic to the problem when assuming that 
the purpose of an action is determined by its position in a workflow, as we do 
in this paper. As a consequence, achieving a purpose amounts to the succesful 
execution of the associated workflow, which is called the Workflow Satisfiability 
Problem (wsp) in the literature [ 12 ] and is known to be NP-hard already in the 
presence of one Sod constraint [33] . Several works have proposed techniques to 
solve both the off-line and the on-line m version of the WSP but none 

considers purpose-aware policies as we do here. 
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Indeed, we are not the first to use first-order ltl for the specification of 
security policies. For example, [5^ shows how to express various types of Sod 
constraints in the Role Based Access Control model by using first-order ltl. 
However, the paper provides no method for the run-time monitoring of such 
constraints and do not discuss if and how the approach can be used in the 
context of workflow specifications. Instead, the work in [13] uses (a fragment of 
propositional) ltl to develop algorithms for checking the successful! termination 
of a workflow. Both works do not discuss purpose-aware policies. To the best of 
our knowledge, only the approach in |1] shares with ours the use of first-order 
LTL to specify and enforce utility and privacy in business workflows. The main 
difference is in the long-term goal: we want to give rigorous foundation to spec¬ 
ification and verihcation techniques for purpose-based policies, while |4] is seen 
as a first step towards to the development of a general, clear, and comprehensive 
framework for reducing high-level utility and privacy requirements to specihc op¬ 
erating guidelines that can be applied at individual steps in business workflows. 
It would be an interesting future work to see if and how the two approaches can 
be combined together in order to derive purpose-aware policies from high-level 
privacy requirements typically found in laws, directives, and regulations. 

Our choice of using a first-order ltl formula (Section 3.1) as the semantics 
of purpose has two main advantages. First, it allows us to reuse well-known 
techniques to specify access control policies, what we call data- and rule-centric 
policies, by using (fragments of) first-order logic (see, e.g., |22I3] 1. Second, it 
allows us to reuse the techniques for the specification and enforcement of work- 
flows put forward by the declarative approach to business process specihcation 
in |2I34I23| . However, these works focus on tasks and their execution constraints, 
disregarding the security and privacy aspects related to accessing the data ma¬ 
nipulated by the tasks. A first proposal of adding the data dimension to this 
approach is in which has been from which we have borrowed the construc¬ 
tion of the automata for off-line and on-line verihcation in this paper (Section]^. 
The choice of considering hrst-order ltl over hnite instead of inhnite traces goes 
back to [T5] in which it is argued that this is the right choice for business process 
which are supposed to terminate as the workhows associated purposes, which 
can be achieved in this way. In general, monitoring hrst-order ltl formulae is 
undecidable |7] but, under the hnite domain assumption, [T5| shows decidability. 
Such an assumption is reasonable in our framework where subjects are usually 
employees of a company (e.g., the job hunting organization in Section]^ whose 
number is bounded. Our verihcation techniques are also related to mechanisms 
for enforcing security policies, such as |28l,SI31j . However, these works mainly 
focus on access or usage control policies and are of limited or no use for purpose- 
based policies considered in this paper. 
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